Base station assistance for random access performance improvement

ABSTRACT

A base station (BS) may be configured to assist in the detection of a random access (RA) request failure and in clued an antenna configured to receive a RA request; a processor configured to decode the RA request; and a transmitter configured to transmit an aggregate RA response message comprising one or more RA responses that respond to one or more received and decoded RA requests.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. application 61/172,072 filed Apr. 23, 2009 and U.S. application 61/183,700 filed Jun. 3, 2009, which are incorporated by reference as if fully set forth.

FIELD OF INVENTION

This application is related to wireless communications.

BACKGROUND

Two issues that currently exist in wireless broadband systems are latency of random access (RA) failure detection on the subscriber side and collisions. An RA attempt fails when the BS fails to receive the RA signal correctly either due to collision, i.e., two or more users (subscribers) use the same RA opportunity, or due to an insufficient signal level.

The first issue is the latency issue of RA failure detection on the subscriber side. In scheduling-based access systems, RA accommodates new access needs, e.g., new users, existing users' new requirements, etc. Broadband Wireless Access systems, e.g., worldwide interoperablility for microwave access (WiMAX), and long term evolution (LTE), are typical scheduling-based access systems, where a base station (BS) controls the use of the air link resources.

When a RA failure occurs, the subscriber needs to detect it and then take actions accordingly, e.g., retry, or ramp up its transmission power. A commonly-used mechanism for a subscriber to detect the failure of its random access attempt is timer-based, i.e., after waiting a pre-defined time period without getting the expected response, the subscriber assumes that its previous RA attempt failed, where the expected response depends on the purpose of the RA.

The pre-defined time period may play a role in a timer-based RA failure detection mechanism because the recovery from a RA failure has to wait for the pre-defined time that needs to be sufficiently long enough to process the RA request receptions and responses under the worst-case considerations, e.g., the heaviest traffic loading.

The second issue relates to collision scenarios. A collision occurs when two or more subscribers choose the same RA opportunity, where a RA opportunity refers to the opportunity for subscriber to send a RA request, for example, a RA opportunity in IEEE 802.16 systems consists of a RA channel and a RA code sent on the RA channel. When a collision occurs, there are several possible results. The first result is that the BS detects nothing. The second result is that the BS detects a collision. The third result is that a single RA Request is erroneously detected by the BS in the RA opportunity with collision.

SUMMARY

A base station (BS) may be configured to assist in the detection of a random access (RA) request failure and include an antenna configured to receive a RA request; a processor configured to decode the RA request; and a transmitter configured to transmit an aggregate RA response message comprising one or more RA responses that respond to one or more received and decoded RA requests.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:

FIG. 1 shows an example wireless communication system including a plurality of WTRUs, a BS, and an RNC.

FIG. 2 is a functional block diagram of a wireless transmit/receive unit (WTRU) and the BS of FIG. 1.

FIG. 3 shows a sample TDD frame structure.

FIG. 4 shows an example ranging RA region and a BS's ranging RA response.

FIG. 5 shows an example of a BS's ranging RA response per RA region or per RA types when a RA region is shared by multiple RA types.

FIG. 6 is a diagram of an example of a single BS RA response message for contention-based bandwidth request.

FIG. 7 shows an example of an uplink data collision after RA requests when HARQ is not used.

FIG. 8 shows an example of an UL data region collision after RA request when UL HARQ is used.

FIG. 9 is a diagram of an example using BS-Assistance information in a RA timer or a negative acknowledgement (NACK).

DETAILED DESCRIPTION 1. Introduction

When referred to hereafter, the terminology “wireless transmit/receive unit (WTRU)” includes but is not limited to a user equipment (UE), a mobile station (MS), a fixed or mobile subscriber station (SS or MS), an advanced mobile station (AMS), a pager, a cellular telephone, a personal digital assistant (PDA), a computer, or any other type of user device capable of operating in a wireless environment. When referred to hereafter, the terminology “base station (BS)” includes but is not limited to a BS, a site controller, an access point (AP), an advanced base station (ABS), a Node-B, or any other type of interfacing device capable of operating in a wireless environment. The solutions and mechanisms described herein may be applicable to TDD, FDD, and other systems.

FIG. 1 shows a wireless communication system 100 including a plurality of WTRUs 110, a BS 120, and a radio network controller (RNC) 130. As shown in FIG. 1, the WTRUs 110 are in communication with the BS 120, which is in communication with the RNC 130. The WTRUs 110 are configured to receive data transmissions from the BS 120 over a high speed shared data channel. The BS 120 and/or WTRUs 110 are configured to detect random access (RA) failures and collisions, as described herein. Although only three WTRUs 110, one BS 120, and one RNC 130 are shown in FIG. 1, it should be noted that any combination of wireless and wired devices may be included in the wireless communication system 100. For example, although the RNC 130 is shown in the wireless communication system 100, the RNC 130 may not exist in the system 100 and may be included in the BS 120 or any other entity in the system 100. It should be understood that the communication between the WTRUs 110, BSes 120, and RNC 130 or other networks like the Internet may be done using packet-based communication.

FIG. 2 is a functional block diagram 200 of the WTRU 110 and the BS 120 of FIG. 1. As shown in FIG. 2, the WTRU 110 is in communication with the BS 120 and both may be configured to detect random access (RA) failures and collisions, as discussed below.

In addition to the components that may be found in a typical WTRU, the WTRU 110 includes a processor 115, a receiver 116, a transmitter 117, and an antenna 118. The processor 115 is configured to detect RA failures and collisions. The receiver 116 and the transmitter 117 are in communication with the processor 115. The antenna 118 is in communication with both the receiver 116 and the transmitter 117 to facilitate the transmission and reception of wireless data.

In addition to the components that may be found in a typical BS, the BS 120 includes a processor 125, a receiver 126, a transmitter 127, and an antenna 128. The processor 125 is configured to detect RA failures and collisions. The receiver 126 and the transmitter 127 are in communication with the processor 125. The antenna 128 is in communication with both the receiver 126 and the transmitter 127 to facilitate the transmission and reception of wireless data.

2. Example Frame Structure

FIG. 3 shows an example of a TDD frame structure that currently corresponds to the IEEE 802.16m TDD frame structure, although other frame structures can of course be used with the embodiments described herein. Regardless of channel bandwidth (5, 7, 8.75, 10, or 20 MHz), the superframe 310 may be 20 ms in length as shown and may be divided into four 5 ms frames 320. The frames 320 may be further divided into 5-8 subframes 330. These subframes 330 may each contain, five, six, seven, or nine OFDM symbols, depending on the type of subframe 330 in use.

Each TDD subframe 330 contains a downlink portion 340 and an uplink portion 350, separated by a TTG (Transmit/Receive gap) 360 and an RTG (Receive/Transmit gap) 380, inserted between transmit and receive, or receive and transmit, respectively. Downlink/Uplink ratios may vary for the 5, 7, 8.75, 10, and 20 MHz bandwidths. Some examples of Downlink/Uplink ratios are: 8/0, 6/2, 5/3, 4/4, 3/5.

FIG. 3 shows the frame structure for 5, 10, and 20 MHz TDD with 5/3 DL/UL split.

A single downlink frame 340 may contain multiple bursts of varying size and type carrying data for several WTRUs. The frame size could also be variable on a frame-by-frame basis. Each burst may contain multiple concatenated fixed-size or variable-size packets or fragments of packets received from higher layers.

The uplink subframe 350 may be made up of several uplink data bursts from different WTRUs. A portion of the uplink subframe 350 may be set aside for contention-based access, also called Random Access (RA), that may be used for a variety of purposes, including ranging for UL, time, and power adjustments during network entry as well as periodically afterward. The RA channel may also be used by WTRUs to make uplink bandwidth requests. In addition, best-effort data may be sent on this contention-based channel, particularly when the amount of data to send is too small to justify requesting a dedicated channel.

3. Random Access (RA)

In scheduling based wireless broadband access systems, Random Access (RA) refers to an uplink (UL) region that is allocated for WTRUs to access. It is also referred to as contention-based access. The UL region allocated for RA may be called a Random Access (RA) region.

A RA region commonly includes RA channels, where a RA channel is physically modulated to carry certain information codes. The information code carried by a RA channel is called a RA code. In some RA code designs, multiple codes with certain orthogonal properties can be transmitted by different WTRUs in the same RA channel. For example, in IEEE 802.16 systems, a Code Division Multiple Access (CDMA)-like RA code may be used, so that one RA channel may be accessed by multiple WTRUs with different RA codes.

A RA opportunity may refer to the opportunity that a WTRU uses to transmit its RA request. When a RA channel may carry multiple RA codes, a RA opportunity may be a combination of a RA channel and a RA code. When a WTRU needs to send a RA request, it may transmit a specific RA code in a RA channel.

After sending a RA request, the WTRU waits for the BS to provide a response to its RA request that is identified by the RA opportunity that the WTRU used to send the RA request, e.g., the location of the RA region, RA channel, and RA code. The expected response varies with the intention of the WTRU's RA request.

3.1 RA Use Cases

The RA opportunities for different RA use cases may be identified by different RA regions allocated by the BS or by different RA codes domains/different RA channels in the same RA region. At least four use cases of Random Access (RA) may exist: initial access for a new subscriber (WTRU) to join the network (initial ranging); Handover of a subscriber (WTRU) from one BS to another BS (HO ranging); periodic maintenance of the uplink (UL) transmission parameters (periodic ranging); and bandwidth request for existing subscriber (WTRU) (contention-based bandwidth request).

Initial ranging is a process for a new WTRU to initiate communication with a BS. The WTRU sends an initial ranging request in an initial ranging RA opportunity to the BS, for example, an initial ranging code in an Initial Ranging RA channel. After sending its initial ranging request, the WTRU waits for a response from the BS. The expected response to an initial ranging request may be a ranging status notification with or without UL transmission parameter adjustments.

HO ranging is a process for a WTRU to initiate communication with the target BS during handover from one BS to another BS. The WTRU sends a HO ranging request in a HO ranging RA opportunity to the BS, i.e., a HO ranging code in a HO ranging RA channel. After sending its HO Ranging request, the WTRU waits for a response from the BS. The expected response to a HO ranging request may be a ranging status notification with or without UL transmission parameter adjustments.

With respect to periodic ranging, since each WTRU may be a different distance from a BS, it may be important in the uplink to synchronize symbols in both time domain and frequency domain and equalize the received power levels among the various active WTRUs. In the uplink, the active WTRUs may need to be synchronized to at least within a cyclic prefix guard time of one another. Otherwise, significant intercarrier and intersymbol interference may result. Similarly, although downlink power control may be used in order to reduce spurious other-cell interference, it may not be not strictly required. Uplink power control may (1) improve battery life, (2) reduce spurious other-cell interference, and (3) avoid drowning out faraway WTRUs in the same cell that are sharing an Orthogonal Frequency Division Multiplexing (OFDM) symbol with them.

This periodic ranging process, when initiated, may require the BS to estimate the channel strength and the time/frequency of the received UL signals from the WTRU in question, and then send the necessary UL transmission parameter adjustments, e.g., time, frequency, and/or power level, to the WTRU. When the WTRU uses unicast UL allocation, the BS may estimate the received unicast UL data from the WTRU to determine if UL transmission parameter adjustment is needed. When the WTRU does not have unicast UL allocation and the periodic ranging is initiated, the WTRU needs to use a periodic ranging RA opportunity to send the BS a periodic ranging request. After sending its periodic ranging request, the WTRU waits for a response from the BS. The expected response to periodic ranging request may be a ranging status notification with or without UL transmission parameter adjustments

A contention-based bandwidth request may be a process that a WTRU uses to request UL bandwidth by sending a Bandwidth Request (BR) RA request. The WTRU may send a BR RA request in a BR RA opportunity to the BS, i.e., a BR RA code in a BR RA channel. After sending a BR RA request, the WTRU waits for a response from the BS. The expected response to a BR RA request may be an UL bandwidth grant.

4. Embodiments Addressing Latentcy and Collisions

4.1 Latency

Within this or other systems, there are several embodiments that may address the latency issue of RA failure detection at the WTRU. Generally, the embodiments may use BS assistance to help the WTRUs in the RA-failure detection, so that the WTRUs may detect the failures of their RA attempts timely and accurately, and then start their RA recovery processes accordingly.

In a first embodiment, the BS may send responses to all the received RA requests in a RA region in the same aggregate BS RA response message and this aggregate BS response may be sent at the earliest possible BS RA response opportunity. Depending on the purpose of the RA request, the BS RA responses may be ranging status notifications with or without parameter adjustments, resource allocations, or simple acknowledgements indicating a successful reception of the RA request.

In the event that no RA request is successfully received by the BS in a RA region, the BS may not transmit the response message or the BS may transmit a null message.

Upon receiving and decoding a BS RA response message that contains responses to the successful received WTRU RA requests, a WTRU may deterministically detect if its own RA request was successfully received at the BS. The WTRU does this by checking whether the aggregate BS RA response message contains a response to its RA request, for example, a RA channel plus a RA code in 802.16 systems. If the aggregate BS RA response message does not contain any response to its RA request, the WTRU may consider that its RA request failed and then start its RA recovery process. This recovery process could begin immediately, without waiting for a timer out, such that the latency of RA failure detection at WTRU side is significantly reduced.

Another benefit of using an aggregate BS RA message may be overhead reduction as the BS sends the responses to all the received RA requests in the same aggregate BS RA response message, compared to sending an individual TA response message to each RA request. The overhead reduction comes from saving multiple message headers and having a more efficient way to identify the RA opportunities in one aggregate message rather than identifying them each individually in separate messages.

4.1.1 Initial Ranging Request

For example, the BS may allocate a ranging RA region in the UL in order to provide initial ranging opportunities for the new WTRUs to join the network. A new WTRU, after acquiring the essential system configuration parameters and synchronized with the downlink (DL) of the BS, may start the initial ranging process by sending an initial ranging request, i.e., transmitting a selected initial ranging RA code in a selected initial ranging channel. After receiving and decoding an initial ranging region, the BS may send an aggregate RA response message at the earliest possible BS initial ranging RA response opportunity. The aggregate RA response message may contain initial ranging RA responses to all the successfully received and decoded initial ranging RA requests in the initial ranging RA region. For each successfully received and decoded initial ranging request, the BS's RA response may contain the ranging status and the necessary UL transmission parameter adjustments.

As shown in FIG. 4, after an UL initial ranging region 1010, the earliest BS initial ranging RA response opportunity may be determined by the BS's scheduler that manages and allocates the radio link resources based on the BS's real-time traffic load and traffic composition. For an initial ranging region in frame n 1000, the earliest BS initial ranging RA response opportunity 1035 may be a DL frame 1020 of frame n+1 1030, i.e., the next DL frame after the UL frame with the initial ranging region, if the BS scheduler can accommodate the initial ranging RA aggregate response message in it after other higher priority traffic data; otherwise, the earliest BS initial ranging RA response opportunity 1045 may be the DL frame of frame n+2 1040 or later.

After sending an initial ranging RA request, the WTRU waits for the initial ranging RA response from the BS. Once the initial ranging RA response message is received and decoded, the WTRU attempts to identify the response to its request based on the used initial ranging RA channel and initial ranging RA code. If the BS aggregate initial ranging RA response message contains a response to the WTRU's request, the WTRU may consider its initial ranging RA request successful and moves to the next step according the given response. If the BS initial ranging RA aggregate response message does not contain a response to the WTRU's request, the WTRU may consider its initial ranging RA request failed and it can immediately start the initial ranging RA recovery process.

The use of a BS initial ranging RA response message containing the responses to all successfully received and decoded initial ranging RA requests in an initial ranging region may make it possible for the WTRUs to timely and deterministically detect the status of their initial ranging RA attempts. If a WTRU detects a failure of its initial ranging RA request, the initial ranging RA recovery process may be started immediately, minimizing the latency in the initial ranging RA failure detection and recovery.

Comparing this to a method where the BS sends separate initial ranging responses to each successfully received and decoded initial ranging RA request, the aggregation of the responses to the successfully received and decoded initial ranging RA requests in one BS initial ranging RA response message reduces the overhead of MAC encodings, as it saves multiple MAC headers and also it may have more efficient way to identify the RA requests when aggregating them together.

An initial ranging RA timer may still be used to handle the exceptions, such as message delivery errors, in order to improve overall system robustness.

4.1.2 HO Ranging Request

A similar embodiment may also be applied to the HO ranging RA process where the HO ranging RA opportunities may be in a separate RA region. Alternatively, as shown in FIG. 5 the HO ranging RA opportunities may share the same RA region 1110 as initial ranging opportunities as shown in frame n 1100. For example, in IEEE 802.16 systems, the initial ranging and HO ranging may share the same RA region where they are distinguished by using different RA codes.

When the HO ranging shares the same RA region with the initial ranging, the BS may send one RA response message 1135 containing the responses to all successfully received and decoded initial ranging RA requests and HO ranging RA requests at the earliest BS initial/HO ranging response opportunity (in frame n+1 1130 for the HO ranging RA request). Alternatively, the BS may send two separate aggregate RA response messages 1138, 1145, one for initial ranging and one for HO ranging, at the earliest BS HO ranging RA response opportunity and the earliest BS initial ranging RA ranging response opportunity in frames n+1 1130 and n+2 1140, respectively. The earliest BS initial ranging RA response opportunity may be different from the earliest BS HO ranging RA response opportunity, depending on the BS scheduler's decision regarding the priorities of those RA responses and the BS's real-time traffic load and traffic composition.

4.1.3 Periodic Ranging Request

In addition, a similar embodiment may also be applied to periodic ranging RA process. Similarly, the periodic ranging RA opportunities may be in a separate RA region. In this case, after each periodic ranging RA region, the BS sends a periodic ranging RA response message containing the RA responses to all successfully received and decoded periodic ranging RA requests, at the earliest possible BS periodic ranging response time.

The periodic ranging RA region may have a different PHY channel design from the initial ranging/HO ranging RA region, as it may be for the random access from the WTRUs that have been synchronized with the BS in the UL.

Alternatively, the periodic ranging RA opportunities may share the same RA region with other ranging types, e.g., initial ranging and/or HO ranging. In this case, after each ranging RA region, the BS may sends one single ranging RA response message containing the RA responses to all successfully receive and decoded ranging RA requests including all ranging types, at the earliest possible BS ranging RA response time. Alternatively, the BS may sends multiple ranging RA response message, one for each ranging types or any combinations of the ranging types supported in the ranging RA region, at the same or different earliest RA response time.

4.1.4 Contention Based Request

In another embodiment, with the contention-based bandwidth Request RA, the BS RA response messages may contain the resource allocations that may be located in the next UL region or spread in the next multiple UL regions. As shown in a simplified frame shown in FIG. 6, for the RA region 602 in frame n−1 600, the BS sends a BS RA aggregate response message 611 in the DL 612 of frame n 610, which contains the responses to all the correctly received RA requests, where the responses 611 may contain the resource allocations 616 in frame n 610 or the next several frames 620.

The BS response 611 may also indicate a future sub-frame where UL resource allocation control signal, e.g., Advanced-MAP (A-MAP) in IEEE 802.16m, containing the actual allocation may be found.

In this way, the BS RA aggregate response 611 also serves as the acknowledgement to the WTRUs for their bandwidth request RA requests sent in the previous bandwidth request RA region. That is, the BS RA aggregate response message may serve two functions: one to allocate resources; and the other to acknowledge WTRUs that used the previous RA region.

For a WTRU that used a RA opportunity for an UL bandwidth request in the previous bandwidth request RA region, if the WTRU receives the expected response from the BS RA aggregate response, it may consider that its RA attempt was successful and also knows where its UL unicast allocation is. If the WTRU does not receive its expected response in the BS RA response, it may recognize that its RA attempt failed and it may start the recovery process immediately or at such time as makes sense.

4.1.5 Additional Embodiments Regarding Responses

In another embodiment, after sending a RA request, if the WTRU does not receive a response in the RA response message from the BS, it may start the RA recovery procedure, unless a maximum number of allowed RA attempts have been reached.

Alternatively, in another embodiment, an explicit ACK may be sent immediately upon detection of the RA request. For a RA request that requires resource allocation, the actual resource grant may be sent at a later time when resources are available.

Upon receiving an ACK for a RA request requiring resource allocation, the WTRU may start a timer. Expiration of the timer without grant/response may be a cause for the WTRU to retry the access procedure. This may prevent the WTRU from waiting too long in the event of a reception error.

In another embodiment, in the BS RA aggregate response message, the successfully received and decoded RA requests are identified by the RA opportunity descriptors, e.g., the RA region, the RA channel, and the RA code (as used, for example in IEEE 802.16 systems), or identifiers derived from the RA opportunity descriptors. If the RA opportunity descriptors are used in the BS RA response message for a RA region, the coding efficiency may be improved by using a two-level list, i.e., listing the RA channels with at least one RA code received and decoded and then, for each listed RA channel, listing all received and decoded RA codes, comparing to using an one-level list of the pairs (RA channel, RA Code) for the received and decoded RA opportunities.

In another embodiment, the ACK may be sent per code and RA channel combination, together called a RA opportunity. RA opportunities may be partitioned into groups. For each group, all successfully received RAs are signaled. For each access group with N opportunities, up to Kmax received RAs may be signaled. The number K may be signaled, which requires log2 (Kmax) bits. An index to the combination of successful RA's may be signaled, which requires log2(N over K) bits. An index may be reserved to signal the event where K>Kmax.

In another embodiment, the BS assists the WTRUs to have an improved time period for the RA timer that is dynamic and varies with the system loads. For example, for the RA requests resource allocations, when the system is lightly loaded, the required resources can be allocated quickly, therefore the RA timer value can be smaller. When the system is heavily loaded, then the required resources will be allocated spreading in the time domain, therefore the timer value should be larger. It is difficult or impossible for the WTRUs to dynamically change their RA timer because the WTRU does not have the system loading information without being informed by the BS. With BS assistance, after the BS receives/processes a RA region, it sends out a broadcast message, telling the WTRUs the RA timer values for the given RA region, based on the BS's knowledge about how long it will take to finish responding to those correctly received RA requests. Alternatively, sending time is unspecified and the WTRU follows the last RA timer value available.

When multiple classes of RA requests are supported, if the RA class information is provided in the received RA requests, the BS may also send multiple RA time values, each for a specific RA request class. An RA timer setting broadcast message may be very short, as it only contains small numbers, i.e. the RA timer values. This proposed embodiment may also apply to the detections of both collision-caused RA failure and power-too-low-caused RA failure. If the WTRU does not receive the expected RA response within the given time, it may start the RA recovery procedure unless the maximum number of allowed RA attempts has been reached.

4.2 Collisions

In a first method to address collisions, all wireless transmit/receive units (WTRUs) may use distinct codes, however due to receiver limitations, more codes are used than can be detected. The first result may be that not all codes are detected, but those that are detected are correct. This is a problem only if all WTRUs choose the same channel again. The second result is that false detections are made. This would be a low probability event and the recovery from it would be in a verification stage.

A first embodiment may address the UL data collision problem caused by missed-detection of RA collisions when UL Hybrid Automatic Repeat Request (HARQ) is not used. A missed-detection of RA collision happens when the BS erroneously detects a single RA request 1210 (in FIG. 7) in a RA opportunity that had a RA collision, i.e., accessed by two or more WTRUs. If the expected RA response 1235 may involve a unicast UL data allocation, for example, in the contention-based UL bandwidth request RA process, the BS may allocate a unicast UL allocation to the decoded RA request 1210. However, two or more WTRUs that used the same RA opportunity 1210 may then transmit in the UL allocation 1238, thus resulting in data region collision.

When UL HARQ is not used for the UL transmission, the involved WTRUs may detect the UL data region collision by a failure of receiving the expected response from the BS to their UL data if their UL data requires certain response, for example, as part of hand-shaking protocol data; otherwise, the involved WTRUs may not be able to detect such an UL data region collision at the MAC layer. The proposed embodiment may use the BS's assistance to the WTRUs in detecting such an UL data region collisions. The BS has the knowledge about which UL data allocation is for a RA response and the BS also has the knowledge if the UL data region has been successfully received. Therefore, in case of UL data region collision, the BS can use its knowledge to send an indication to the WTRUs to inform the failure of reception of the UL data region allocated for a RA request. Such an indication of UL data region collision may be called as RA-initiated UL data Negative-ACKnowledgement (NACK).

When the WTRUs that used the given UL allocation receive such a RA-initiated UL data NACK from the BS, they may realize that an error occurred in their “on-going” procedure, and an error recovery is needed.

In a RA-initiated UL data NACK 1245 sent by the BS, the UL data region may be identified by the RA request to which the UL data allocation was given as the response, where the RA request may be identified by the RA request descriptors, for example, the RA region, the RA channel, and the RA code, or an identifier derived from these RA descriptors.

In a RA-initiated UL data NACK 1245 sent by the BS, the UL data region may also be identified by the UL data allocation descriptors, for example, frame index, subframe index, LRU (Logical Resource Unit) index, etc, or an identifier derived from these UL allocation descriptors.

The BS may send a RA-initiated UL data NACK 1245 as a MAC control signal, for example, in the IEEE 802.16 systems, such a RA-initiated UL data NACK may be encoded as a control message, a control signaling header, or a subheader or extended header of a MAC PDU (Protocol Data Unit), or an Advanced-MAP (A-MAP) Information Element (IE).

Another embodiment may address the UL data collision problem caused by missed-detection of a RA collision when UL HARQ is used. In this case, the UL data collision caused by missed-detection of a RA collision may cause substantial resource waste, because it may force the collided WTRUs to repeatedly retransmit and hence re-collide until reaching the max allowed number of HARQ retransmissions. With UL HARQ, detecting an UL data region collision may require additional attempts and/or other techniques than just normal UL data HARQ decoding, because a single burst error may be difficult to tell it is the result of normal link error or a collision.

As shown in FIG. 8, multiple RA request opportunities 1310 are transmitted in a frame n in an uplink, and in the frame n+1 the BS aggregate RA response message 1335 provides responses to the RA request 1310 and other requests. After receiving and decoding the first UL transmission in an UL data allocation as the response to a RA request 1310, the BS may still be able to detect a collision. For example, the BS may consider a collision is detected if the UL data region 1338 experiences an abnormally high level of errors based on the channel coding, such as Incremental Redundancy HARQ (IR HARQ), or if it observes other abnormal physical signal changes, e.g., channel delay spread.

When receiving and decoding a subsequent UL HARQ retransmission 1338 but before reaching the maximum number of HARQ retransmissions, the BS may be able to detect a collision in an UL data allocation as the response to a RA request. For example, the BS may consider a collision is detected if it observes no gain has been obtained from the UL HARQ retransmissions.

Once detected, an UL data region collision may be handled by using the BS's assistance to help the WTRUs to timely detect the error condition, stop UL HARQ retransmissions, and enter an error recovery process. The BS assistance may be an indication signal sent by the BS to the WTRUs, e.g., a RA-initiated UL data Negative ACKnowledgement (NACK) 1350 in the downlink in frame n+3 in FIG. 8.

When receiving such a RA-initiated UL data NACK 1350 from the BS, the WTRU may stop the HARQ retransmission process and enter the random access recovery process immediately.

Similar to the previous embodiment, the RA-initiated UL data NACK 1350 signaled by the BS may be encoded as a MAC control signal, for example, in the IEEE 802.16 systems, a control message, or a control signaling header, or a subheader or extended header of a MAC PDU (Protocol Data Unit), or an Advanced-MAP (A-MAP) Information Element (IE).

In addition, if the synchronized UL HARQ is used, the RA-initiated UL data NACK sent by the BS may be the same control signal used to terminate the synchronized UL resource allocations for UL HARQ retransmissions 1350, for example in frame n+3 in FIG. 9. For example, in IEEE 802.16 systems, a CDMA allocation A-MAP IE with zero allocation can be used by the BS to signal the RA-initiated UL data NACK and also to terminate the synchronized UL resource allocations for UL HARQ retransmissions.

Also, if the non-synchronized UL HARQ is used, the RA-initiated UL data NACK signaled by the BS may be a combination of UL HARQ NACK and no UL resource allocated for the HARQ retransmission within a pre-defined time interval after the previous HARQ transmission or retransmission.

Alternatively, if the non-synchronized UL HARQ is used, the RA-initiated UL data NACK signaled by the BS may be a combination of UL HARQ NACK and zero UL resource allocation for the HARQ retransmission. For example, in IEEE 802.16 systems, zero UL resource allocation may be a CDMA allocation A-MAP IE with zero allocation.

When using the zero allocation for the UL HARQ retransmission for an UL allocation following a RA request to terminate its UL HARQ retransmission process, the intended WTRUs may be identified by the previously used RA opportunity descriptors, for example, the RA region, the RA channel, and the RA code, or an identifier derived from these RA descriptors.

Alternatively, when using the zero allocation for the UL HARQ retransmission for an UL allocation following a RA request to terminate its UL HARQ retransmission process, its intended WTRUs may be identified by the previously used UL data allocation descriptors, for example, frame index, subframe index, LRU (Logical Resource Unit) index, etc, or an identifier derived from these UL allocation descriptors.

When using the zero allocation for the UL HARQ retransmission for an UL allocation following a RA request to terminate its UL HARQ retransmission process, the identifiers of its intended WTRUs may be included as information field in the zero allocation control signal or may be masked with the Cyclic Redundancy Check (CRC) of the zero allocation control signal.

The zero allocation control signal may be encoded as a stand-alone UL resource allocation information element, for example, a stand-alone A-MAP IE, where its type value indicates the zero UL allocation.

Alternatively, the zero allocation control signal may be encoded as a special case of the UL allocation IE for the UL allocation following a RA request, for example, the CDMA Allocation IE, where the special case may be indicated by a specific value of an information field in the UL allocation IE.

Another embodiment may address the UL data collision problem caused by missed-detection of RA collisions when UL HARQ is used. The BS may configure a limited number of UL HARQ retransmissions for the UL data region allocated as a response to a RA request, where such a limited number is less than maximum number of UL HARQ retransmissions for other UL allocations. With this embodiment, the WTRU that transmits in an UL allocation following a RA request may exist the UL HARQ retransmission when transmitted n times including the original transmission, where 1≦n≦Max_num_HARQ retransmissions. The value of n may be decided by system configuration. The n-th HARQ NACK from the BS also indicates the termination of the HARQ retransmission process. When receiving the n-th HARQ NACK, the WTRU terminates the UL HARQ retransmission and may enter the random access recovery process.

Another embodiment may address the collision problem where not all codes are detected and where nothing is detected. This embodiment uses a recovery mechanism such that the WTRU may randomize its choice of slot and codes.

Another embodiment may address the RA collision problem where a RA collision is detected. In this example, the BS may send a NACK to notify the WTRUs that the RA failures that the BS detected in the previous RA region are due to collisions. The benefit of sending a NACK and not an ACK is in reduced overhead as NACK signals are the exception rather than the rule.

FIG. 9 is a diagram of a frame using BS-Assistance information in a RA timer or a NACK. When a BS detects a collision in RA, at the next DL opportunity, the BS may send a NACK message 613 to inform the subscribers of the detected collision. This will simultaneously eliminate/minimize the false detection at the WTRU side and reduce the RA latency significantly. The proposed NACK mechanism may be an addition to the WTRU timer-based mechanism, not a replacement. A timer-based mechanism may be employed to be the backup mechanism in certain scenarios.

The embodiments discussed herein may address the detections of both collision-caused RA failure and insufficient signal power RA failure, as well as other causes RA failure.

Although features and elements are described above in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).

Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.

A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any wireless local area network (WLAN) or Ultra Wide Band (UWB) module. 

1. A base station (BS) configured to assist in the detection of a random access (RA) request failure comprising: an antenna configured to receive a RA request; a processor configured to decode the RA request; and a transmitter configured to transmit an aggregate RA response message comprising one or more RA responses that respond to one or more received and decoded RA requests.
 2. The BS of claim 1, wherein the RA request comprises an initial ranging request.
 3. The BS of claim 2, wherein the initial ranging request comprises an initial ranging code in an initial ranging channel.
 4. The BS of claim 2, wherein the one or more RA responses comprise a ranging status notification.
 5. The BS of claim 4, wherein the one or more RA responses comprise uplink (UL) parameter adjustments.
 6. The BS of claim 1, wherein the RA request comprises a handover (HO) ranging request.
 7. The BS of claim 6, wherein the HO ranging request comprises a HO ranging code in a HO ranging RA channel.
 8. The BS of claim 7, wherein the one or more RA responses comprise a ranging status notification.
 9. The BS of claim 8, wherein the one or more RA responses comprise uplink (UL) parameter adjustments.
 10. The BS of claim 1, wherein the RA request comprises a periodic ranging request.
 11. The BS of claim 10, wherein when the BS receives and decodes the periodic ranging request, the BS estimates the channel strength and the time/frequency of the received UL signals corresponding to the periodic ranging request.
 12. The BS of claim 10, wherein the one or more RA responses comprise a ranging status notification.
 13. The BS of claim 12, wherein the one or more RA responses comprise uplink (UL) parameter adjustments.
 14. A wireless transmit/receive unit (WTRU) that detects failure of a random access (RA) request comprising: a transmitter configured to transmit a RA request; a receiver configured to receive an aggregate RA response message; and a processor configured to determine whether the RA request was successful by determining if the aggregate RA response message comprises a RA response corresponding to the RA request.
 15. The WTRU of claim 14, wherein the RA request comprises an initial ranging request.
 16. The WTRU of claim 14, wherein the RA request comprises a handover ranging request.
 17. The WTRU of claim 14, wherein the RA request comprises a periodic ranging request.
 18. A base station (BS) that assists in random access (RA) collision detection comprising: an antenna configured to receive a RA request and to receive an uplink (UL) data burst; a processor configured to decode the RA request, construct and schedule an RA response to the RA request, schedule UL data allocation in response to the RA request, and decode the UL data burst; and a transmitter configured to transmit a RA response to the RA request, the transmitter further configured to transmit an UL allocation in response to the RA request, and also transmit a RA-initiated UL data negative acknowledgement (NACK) on a condition that data was not received in an UL data region corresponding to the RA request.
 19. A method to assist in detection of random access (RA) request failure comprising: receiving and decoding a RA request; and transmitting an aggregate RA response message comprising one or more RA responses that respond to one or more of the received and decoded RA requests.
 20. A method for detecting a random access (RA) failure, the method comprising: transmitting a RA request; receiving an aggregate RA response message comprising one or more RA responses; and determining whether the RA request was successfully transmitted by determining if the aggregate RA response message comprises a RA response corresponding to the RA request. 